When programs are coded with programming languages using symbolic names, such as Java™ programming language, a ‘debugger’ program can be used. (Java is a trademark of Sun Microsystems, Inc. in the United States, other countries, or both). A debugger is a program controlling the execution of a program to be debugged, allowing a developer or programmer to step through the program, catch data, and monitor conditions, such as values of variables, to correct a problem. When the programming language does not use symbolic names, one other way to debug a program is to include, at strategic points in the code, macro instructions which will generate a trace in a trace file at execution time. The trace file is analyzed after execution with a trace analyzer.
Basically, a trace tool provides parameter tracing for dumping to the trace file the parameters provided to a function, entry-exit tracing to follow a calling sequence of functions, and event tracing to track the occurrence of specific events in a program. TraceMon Plus is a tracing and logging utility for Visual C++® 6.0 language sold by TWI AG (Technisch-wissenischaftliche Informatik). (Visial C++ is a trademark of Microsoft Corporation in the United States, other countries, or both.) TraceMon Plus consists of a TMPlus program and a trace analyzer CTracer. In TraceMon Plus, in order to follow execution of functions in the code, a trace is activated with a CTRACE SCOPE, a macro used at an entry point of a function. This macro detects when the function exits.
With most of the tracing tools available today, after the trace macros have been inserted in the source code, at execution time the trace elements are generated and stored in a trace file. A convenient function of a trace analyzer enables users to view and manipulate trace files easily and rapidly. User-friendly trace analyzers use a Graphical User Interface viewer as described in the RD4108301 IBM article of the Research Disclosure journal Number 415 of Nov. 1998 published by Kenneth Mason Publication Ltd. A simple tree structure illustrates nested functions of the code. Error code searching and simple graphics are provided to display states of trace information. However, even using a graphical trace analyzer, it is not possible today to analyze more deeply the execution of nested functions. More particularly, there is a need for identifying the execution of functions not coded with exceptions, but coded with return codes. This is the case of code developed in operating systems when commands or applications have no need of exceptions. It would be of great help to be able to follow the execution of nested function calls and to know which of the nested functions of a thread of a multi-thread environment have not been executed successfully. When functions are nested, the programmer wants to diagnose the problem in the execution of a thread, tracking it in a tree structure of nested functions and identifying the nested functions that have failed. Non-fatal failures are very difficult to identify as the application being a deamon, despite an error, continues to run, always generating numerous trace logs. The cause of the error cannot be identified because the cause is hidden by a failing event or a correlation of failing events. So there is a need for easily and quickly analyzing a fairly big collection of tracing information (for instance, up to 10 Mbytes of trace log) to identify a problem that occurred sometime in the past and in a piece of code to be located and modified.